Resolution of edit conflicts in audio-file development

ABSTRACT

A processor may store a first version of an audio file and fragment the audio file into at least a first time segment. The processor may receive a first edit to the audio file and identify a first edited version of the first time segment in the first edit. The processor may update the first version of the audio file with the first edit, resulting in a second version of the audio file comprising the first edited version of the first time segment. The processor may receive a second edit to the first version of the audio file and identify a second edited version of the first time segment in the second edit. The processor may determine, based on the second edited version, that the second edit alters an outdated version of the first time segment, resulting in an edit conflict. The processor may notify a user of the conflict.

BACKGROUND

Aspects of the present disclosure relate to development of audio files,more particular aspects relate to version control of audio files indevelopment.

Audio files may be developed by one or more audio developers. An audiofile in development may be stored on a central server. Updates to theaudio file may be uploaded to the central server by audio developersworking on the development project. When updates are uploaded thatconflict with prior updates, one or more audio developers may berequired to manually listen to each updated version in order to identifythe conflicting portions and resolve the conflicts.

SUMMARY

Some embodiments of the present disclosure can also be illustrated as amethod comprising storing a first version of an audio file. The methodmay fragment the audio file into at least a first time segment. Themethod may include receiving a first edit to the audio file, andidentifying a first edited version of the first time segment in thefirst edit. The method may also include updating the first version ofthe audio file with the first edit, resulting in a second version of theaudio file comprising the first edited version of the first timesegment. The method may also include receiving a second edit to thefirst version of the audio file, and identifying a second edited versionof the first time segment in the second edit. The method may theninclude determining, based on the identifying the second edited version,that the second edited version alters an outdated version of the firsttime segment, resulting in an edit conflict. The method may finallyinclude notifying a user of the edit conflict.

Some embodiments of the present disclosure can also be illustrated as acomputer program product comprising a computer readable storage mediumhaving program instructions embodied therewith, the program instructionsexecutable by a computer to cause the computer to perform the methoddiscussed above.

Some embodiments of the present disclosure can also be illustrated as asystem comprising a processor and a memory. The memory may be incommunication with the processor. The memory may contain programinstructions that, when executed by the processor, are configured tocause the processor to receive a first edit to an audio file and receivea second edit to the audio file. The program instructions may also causethe processor to detect an edit conflict between the first edit and thesecond edit. The program instructions may also cause the processor toidentify a relevant user for the audio file and analyze the preferencesof the identified relevant user. The program instructions may also causethe processor to edit, based on the analyzing, the audio file to resolvethe edit conflict.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included in the present application are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent disclosure and, along with the description, serve to explain theprinciples of the disclosure. The drawings are only illustrative ofcertain embodiments and do not limit the disclosure.

FIG. 1 illustrates an example method of analyzing edited audio segmentsto mitigate the negative effects of edit conflicts in an audiodevelopment project, in accordance with embodiments of the presentdisclosure.

FIG. 2A illustrates a graphical representation of an original masteraudio file stored on a central server, in accordance with embodiments ofthe present disclosure.

FIG. 2B illustrates a graphical representation of the audio data of anedited audio file uploaded by an artist, in accordance with embodimentsof the present disclosure.

FIG. 2C illustrates a graphical representation of an edit to an originalaudio file that results in an edit conflict; in accordance withembodiments of the present disclosure.

FIG. 2D illustrates a graphical representation of a resolution to anedit conflict.

FIG. 3 illustrates an example method in which a machine-learning systemmay be utilized to resolve edit conflicts during the development of anaudio file.

FIG. 4 depicts the representative major components of a computer systemthat may be used in accordance with embodiments.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail. It should be understood,however, that the intention is not to limit the invention to theparticular embodiments described. On the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

Aspects of the present disclosure relate to development of audio files,more particular aspects relate to version control of audio files indevelopment. While the present disclosure is not necessarily limited tosuch applications, various aspects of the disclosure may be appreciatedthrough a discussion of various examples using this context.

Audio files contain media designed to be listened to by an end user,such as songs, sound effects, music tracks, and others. These audiofiles contain audio data that is created and developed by musicians,audio engineers, sound designers, and others (collectively referred toherein as “artists”). In some industries and use cases, the process ofcreating and developing a particular audio file may be an iterativeprocess that takes place over time. For example, an artist may developan audio file over the course of a calendar year, during which theartist may work on a first portion of the file, then work on a secondportion of the file, then work on the entire file, then return tofocusing on the first portion of the file.

During this iterative process, it may sometimes be beneficial to store a“master” version of the audio file on a computer, such as a server. Thismaster version of the audio file may represent the most current,accepted version of the audio file. For example, if a musician iscreating a song, the musician may store the most recent version of thesong on a central server, and may create a copy of the song on aworkstation computer to edit. If the musician produces an edit to thesong that the musician enjoys, the musician may upload that edit (e.g.,a version of the audio file that reflects the edit) to the centralserver. That edited version may then become the master version of theaudio file. However, if the musician produces an edit to the song thatthe musician decides should not be incorporated into the final audiofile (e.g., the musician decides the resulting song sounds harsh), themusician may simply delete the edited version of the audio file. Becausethe musician did not merge the edited audio file with the masterversion, the master version remained the most current, accepted versionof the audio file.

However, version control of audio files may be difficult in some usecases. For example, if a musician is working on multiple versions of anaudio file simultaneously, it may be difficult to keep track of eachparticular version of the audio file without listening to each version(e.g., through an audio player). Thus, edit conflicts may be likely toarise during audio-file development. An edit conflict occurs when twoedits to an audio file change the master audio file in different ways.For example, an artist may produce a first edit to a copy of a masteraudio file that is current as of a first particular date. The first editmay change a first time segment of the audio file (e.g., minutes 2through 4 of a song). The artist may then upload the edited audio fileto a server, creating a master audio file that is current as of a secondparticular date.

Subsequently, the artist may move to other projects and, at a latertime, return to the audio file to continue editing. Due to the passageof time, the artist may then mistakenly edit a second copy of the masteraudio file that was current as of the particular date, rather than thesecond particular date. The artist may then attempt to upload the secondcopy of the master audio file to the server, complete with the secondedit. Depending on the nature of the second edit, this may result inseveral different types of edit conflict.

In the first type of edit conflict, referred to herein as a “currentedit conflict,” the second edit would only alter time segments that werenot altered in the first edit (i.e., segments that do not overlap withthe first time segment, such as minutes 5 through 6 of the song in theprevious example). In other words, the second edit would only alter timesegments that are current in the master audio file on the server. Intheory, both edits in a current edit conflict could be applied to themaster audio file simultaneously. For example, if an artist altered afirst time segment (e.g., the first minute of a 10-minute song) and asecond, non-overlapping time segment (e.g., the last minute of the10-minute song), both edits could be uploaded to a master song filesimultaneously.

However, in a current edit conflict, non-overlapping time segments areedited in multiple, separate edits. For example, an artist maymistakenly attempt to upload two edit files to replace the master audiofile. Continuing the previous example, the first edit file may alter thefirst minute of the 10 minute song, but maintain the original state ofthe last nine minutes. The second edit may alter the last minute of thesong, but maintain the original state of the first nine minutes. If thesecond edit is uploaded to the master audio file after the first edit,the second edit may revert the first minute of the song to the originalstate, nullifying the first edit.

In the second type of edit conflict, referred to herein as an “outdatededit conflict,” a subsequent edit would also alter a time segment thathas already been altered by a previous edit. For example, an artist maybe working on an original audio file that is copied from a master audiofile. The artist may alter the first 2 seconds of the original audiofile in a first edit and upload that first edited audio file to themaster audio file. The current master audio file would contain thealtered first 2 seconds. However, in a subsequent edit, the artist maymistakenly edit the original audio file again and alter seconds 2thorough 3 of the original audio file, resulting in a second editedaudio file in which the original first 1 second is original, but seconds2 through 3 are edited. If the artist then uploads this second editedaudio file to the master audio file, an outdated edit conflict wouldoccur. This type of edit conflict is referred to an outdated editconflict because the artist uploaded an edit that altered an outdatedversion of the first 2 seconds of the audio file. In some embodiments,uploading this outdated edit conflict may revert the first second of theaudio file to the original state. This may lead to undesired results ifthe artist prefers the first edit, or would prefer a mixture of thefirst edit and the second edit.

As discussed, in some instances an artist may not realize that an editconflict (either a current edit conflict or an outdated edit conflict)occurs, and may overwrite pervious work performed when merging an editedaudio file with a master audio file. However, in some instances anartist may realize (e.g., when attempting to upload an edited audiofile) that uploading the file would result in an edit conflict. In theseinstances, the artist may be required to listen to both versions of theaudio file (i.e., the previously edited master audio file and thecurrently edited audio file) to identify conflicting time segments. Whenworking on long or complex audio files (e.g., a song or a recording of aspeech), this may be very time consuming. Time spent identifyingconflicting time segments in an audio file may, in some instances, betime that an artist would have been able to spend working on other areasof a project (or other projects), and thus may be very costly from anoperational-cost perspective. For example, in a current edit conflict,an artist may determine that a first edit altered the 1^(st) minute of asong and that a second edit altered the 4^(th) minute of the song. Eventhough the artist would be able, in theory, to merge both edits into amaster audio file containing the edited 1^(st) and 4^(th) minutes, thetime the artist spent identifying the conflicting segments could havebeen better spent elsewhere on the project (e.g., altering the 8^(th)minute of the song).

Further, in the case of an outdated edit conflict, the artist may berequired to spend even more time determining how to merge twoindependently edited and overlapping time segments. For example, anartist may realize that two edits independently edited the first 2minutes of a song. After identifying the outdated edit conflict andlistening to both edited versions of the first 2 minutes of the song,the artist may prefer minute 1 of the first edit and minute 2 of thesecond edit. However, minute 1 of the first edit may not transition wellto minute 2 of the second edit, requiring the artist to perform morework to determine a desirable way to merge the edits together (e.g.,create a short transition segment between minute 1 and minute 2).

For the reasons discussed above, edit conflicts may be particularlycostly in the development of audio files. Further, outdated editconflicts may be even more costly if they result in more required workto merge two conflicting edits.

In some industries and use cases, version tracking of audio files may bemore complicated when multiple artists add to the development of anaudio file simultaneously. For example, a team of sound engineers may beresponsible of developing a set of background sound effects orbackground music for an advertisement. Thus, multiple artists may beworking on the same audio file at the same time. This may result in asignificant increase in edit conflicts throughout the project becausemultiple artists may be creating edits to different copies of the sameversion of an audio file simultaneously. For example, if three artistsall copy an original version of a master audio file to theirworkstations, the first artist may edit minutes 1 through 3 and 5through 6 of the audio file, the second artist may edit minutes 2through 4 of the audio file, and the fifth artist may edit minutes 3through 5 of the audio file. This may result in several edit conflictsif all artists decide to upload their edited versions to the masteraudio file.

In some industries, audio projects that employ a high number of artistsmay also be particularly expensive projects. For that reason, while itmay be more likely for edit conflicts to occur during audio projectsthat employ a high number of artists, edit conflicts in those projectsmay be particularly costly.

Embodiments of the present disclosure mitigate the negative effects ofedit conflicts in audio development projects. In some embodiments of thepresent disclosure, a master audio file may be stored on a central. Thatmaster audio file may be broken up into time segments. The nature ofthose time segments may vary by the embodiment and use case. Forexample, in an embodiment in which a 10-minute song is being developed,the song may be divided into ten 1-minute segments. However, in anembodiment in which a 3-second sound effect is being created, the soundeffect may be broken up into thirty 0.1 second segments. In someembodiments, segments may be of unequal size. For example, in anembodiment in which a recording of two people having a conversation isbeing edited, the length of each segment may be based on the content ofthe conversation (e.g., each sentence may be a segment, or a new segmentmay be created each time the recording switches from one person speakingto the other person speaking).

In some embodiments, the length of segments of a master audio file maybe altered each time an edit to the master audio file is uploaded. Forexample, a song may have a segment that begins and ends at the beginningand ending of a guitar solo (e.g., a “guitar-solo segment”). If anartist uploads an edit to the master song file that shortens the guitarsolo, the length of the guitar-solo segment may be shortened as well.

In some embodiments, segments may be calculated in real time when anartist uploads an edited audio file to a central server that containsthe current master audio file. For example, a processor may performwaveform or spectrogram analysis on the edited audio file to divide theaudio file into segments based on the waveform or spectrogram patternsof the audio file. Continuing the previous example, a processor mayperform waveform analysis on an edited song file and identify thebeginning and end of the guitar solo because the waveform patternscontributed by other instruments of the song abruptly stop at thebeginning of the guitar solo and abruptly start at the end of the guitarsolo. Upon identifying the guitar solo, the processor may create aseparate segment for the guitar solo (e.g., the guitar-solo segment). Insome embodiments, the processor may perform waveform or spectrogramanalysis on the master audio file to identify corresponding segments inthe master audio file.

In some embodiments, segments may be labeled (e.g., tagged withmetadata) during the editing process. For example, when a master audiofile is originally created, the audio file may be broken up intosegments and a unique metadata tag may be attached to each segment. Themetadata tags may remain attached to segments when the audio file iscopied to the workstations of artists on the project. Further, they mayremain attached to segments during the editing process. For example, ifa “guitar-solo” tag is attached to the guitar-solo segment, the tag mayremain attached to the guitar-solo segment after an artist edits theguitar-solo segment.

In some embodiments, a system may label a segment with a note thatidentifies the last time the segment was edited. For example, a centralserver may maintain a master audio file fragmented into segments. Eachsegment may have a timestamp attached to it (for example, in a metadatatag) that identifies the last time that segment was updated. Thesetimestamps may be referred to herein as edit timestamps. When an artistcopies the master audio file to the artist's workstation, the edittimestamp information may transfer with the audio file. Then, when anartist uploads an edited audio file that edits a segment in the masteraudio file, the master audio file may update the edit timestamp of thesegment in the master audio file.

In some embodiments, edit timestamps may be useful in identifyingoutdated edit conflicts by analyzing the edit timestamps of editedsegments. If, for example, two artists copy an original master audiofile, the edit timestamps of all segments may equal the date and time atwhich the original master audio file was fragmented. If a first artistthen uploads an edited file that alters the original first segment inthe audio file, the edit timestamp in the master audio file may beupdated to equal the date and time that the edited file was uploaded. Ifthe second artist then uploads an edited file that also alters theoriginal first segment in the audio file, an edit conflict would occur.The edit timestamp of the first segment in the master audio file couldthen be compared to the edit timestamp of the first segment in theedited audio file. Because the edit timestamp of the edited segmentwould be older than the edit timestamp of the master segment, it wouldbe evident that the second artist was uploading an edit to a segmentthat is no longer current, causing an outdated edit conflict.

FIG. 1 illustrates an example method 100 of analyzing edited audiosegments to mitigate the negative effects of edit conflicts in an audiodevelopment project. Method 100 may be performed, by example, by aprocessor on a computer that maintains a master audio file (e.g., acentral server) or a processor connected to such a computer (e.g., thepersonal workstation of an artist who uploads edited audio files to acentral server).

Method 100 begins with block 102, in which an edited audio file isreceived. In some embodiments, the edited audio file may be received inblock 102 by a central server that maintains a master audio file. Inother embodiments, the edited audio file may be received in block 102 bya processor running a set of instructions that are configured to causethe processor to analyze the edited audio file before being uploaded toa central server (for example, when an artists workstation contains ananalysis program that analyzes audio files before merging them with themaster audio file).

After the processor receives the edited audio file, the processoridentifies, in block 104, the segments of the edited audio file. In someembodiments, block 104 may include fragmenting the edited audio fileinto segments. For example, the processor may perform waveform analysison the edited audio file to identify logical locations for thebeginnings and ends of segments. In other embodiments, the processor mayscan metadata tags attached to segments of the edited audio file. In yetother embodiments, the processor may divide the audio file into an equalnumber of segments based on the length of the audio file, withoutperforming any further analysis (e.g., the processor may divide theaudio file into 10 equal segments).

In block 106, the processor identifies segments of the master audio filethat correspond to the segments of the edited audio file that wereidentified in block 104. In some embodiments, this may includefragmenting the master audio file into segments. For example, theprocessor may perform spectrogram analysis on the master audio file toidentify logical locations for the beginnings and ends of segments. Insome embodiments, the master audio file may have already been fragmentedinto segments. Once the segments of the master audio file areidentified, the processor may attempt to match each segment in theedited audio file with a corresponding segment in the master audio file,creating segment pairs. For example, the processor may perform waveformanalysis on the segments of both files to identify similar waveformpatterns, identify segments of similar (or identical) length, oridentifying segments with matching metadata tags.

Once the corresponding segment pairs are identified, the processoridentifies the segments that were edited by the artist in block 108. Forexample, the processor may analyze the two segments in each segment pairto identify differences between the two segments. Further, block 108 mayalso involve identifying segments that have been added by an editedaudio file (e.g., segments in the edited audio file with nocorresponding segment in the master audio file) or segments that havebeen deleted by an edited audio file (e.g., segments in the master audiofile with no corresponding segment in the edited audio file).

In some embodiments, an artist may be capable of informing the processorof the identities of the segments that the artist has edited. Forexample, an artist may edit a guitar-solo segment in a song, and uploadthe resulting edited file to a server maintaining a master-audio file.Upon uploading the edited file, the artist may identify attach a“currently edited” meta-data tag to the guitar-solo segment that informsthe server that the artist edited the guitar-solo segment. In suchembodiments, the processor of the server may identify that theguitar-solo segment is the only edited segment by detecting that theguitar-solo segment is the only segment with a currently editedmeta-data tag.

In some embodiments, after the processor identifies the edited segmentsin block 108, the processor may separate the edited segments in theedited audio file from the non-edited segments in the edited audio file.In some embodiments, the processor may discard the non-edited segmentsof the edited audio file.

Once the edited segments are identified in block 108, the processorcompares edit timestamps of the edited segments in the edited audio filewith the edit timestamps of the corresponding master-file segments inblock 110. The processor may identify segments for which the edittimestamps in the edited audio file are equal to the edit timestamps ofthe corresponding master-file segments, and may identify segments forwhich the edit timestamps of the edited audio file are older than theedit timestamps of the corresponding master-file segments.

Once the processor compares the edit timestamps in block 110, theprocessor determines in block 112 whether any of the edited segmentsreflect alterations to current segments. The processor may accomplishthis by determining whether block 110 identified any segments for whichthe edit timestamps in the edited audio file matched the edit timestampsof the master audio file. If the processor determines in block 112 thatno edited segment contains alterations to a current segment, then theprocessor proceeds to block 116.

If, however, the processor determines in block 112 that one or moreedited segments reflect alterations to one or more current segments, theprocessor proceeds to update those segments in block 114. In someembodiments, this may entail replacing the corresponding segments in themaster audio file with the edited segments in the edited audio file. Insome embodiments, blocks 112 and 114 may be useful in identifying andresolving current edit conflicts, without a need to alert an artist orother user of the edit conflict. In these embodiments, significantartist time may be saved by avoiding the need for artist to detect andresolve current edit conflicts.

After the processor updates the current segments in block 114, theprocessor proceeds to block 116. In block 116, the processor determineswhether any of the edited segments reflect alterations to outdatedsegments. The processor may accomplish this by determining whether block110 identified any segments for which the edit timestamps in the editedaudio file were older than the edit timestamps of the master audio file.If the processor determines in block 116 that no edited segment containsalterations to an outdated segment, the processor ends method 100 inblock 118.

If, however, the processor determines in block 116 that at least oneedited segment contains an alteration to an outdated segment, an editconflict is detected, and the processor proceeds to obtain theresolution of the edit conflict. The nature of obtaining resolution ofthe edit conflict may vary depending on the embodiment and thecircumstances. For example, in some embodiments, the processor may firstalert the user who uploaded the edited file in block 102 of theconflict, at which point the user may analyze the conflicting segments(e.g., by listening to both segments and providing a resolution to theprocessor).

In some instances, for example, block 116 may detect an edit conflictbecause a first artist uploaded an edited file with an original segment(e.g., a segment that, in the first artist's edited file, reflected thecondition of the segment as it existed when the master audio file wascreated), but a second artist had previously edited that segment anduploaded the edited segment to the master audio file. In thiscircumstance, the processor may identify the original segment in thefirst artist's original file as a subsequent edit to second artist'suploaded segment in the master audio file. In some embodiments, theprocessor may then notify the first artist of the conflict and ask thefirst artist for a resolution. In other words, in some embodiments theprocessor may detect that the first artist is attempting to edit thesegment that was previously edited by the second artist, and notify thefirst artist of the conflict. The first artist may then realize that thesecond artist had edited the segment, and resolve the conflict byselecting the second artist's edited segment.

As discussed in connection with block 108, in some embodiments an artistmay attach a metadata edit flag to the segments in an audio file thatthat artist has edited. In these embodiments, it is less likely that theprocessor would identify edit conflicts in block 116 that resulted froman artist uploading a non-edited version of a segment that waspreviously edited by another artist. This is because those segmentswould likely not be flagged as edited by the artist, and thus would notbe likely to be identified as edited in block 108.

Therefore, in embodiments in which a metadata edit flag is attached toedited segments by an artist, block 116 may be more likely to detectonly outdated edit conflicts. This may be beneficial, as it may preventartists from being notified, in block 120, of edit conflicts that occursimply due to an artist uploading unedited segments.

In some embodiments, the resolution obtained in block 120 may beobtained from a machine-learning process, such as a neural network, thatis trained to create desirable mergers between conflicting edits to anaudio file based on learned preferences of relevant end users. Anexample of such an embodiment is given in more detail in FIG. 3.

In some embodiments, once the resolution of the conflict is obtained inblock 120, the processor can act upon the resolution. This may involvereplacing the master-file segment with the edited segment, discardingthe edited segment, creating a new segment that merges the master-filesegment and the edited segment, or others. After the resolution, method100 ends in block 118.

FIGS. 2A through 2D illustrate simplified graphical representations 200Athrough 200D (referred to herein as “graphs”) of four stages of an audiofile to aid in understanding of the embodiments of the presentdisclosure. In Graphs 200A though 200D, X axis 202 represents thepassage of time in an audio file (e.g., the playback time of a song). Yaxis 204 represents a measurable, editable property of the audio data,such as amplitude at a given frequency. For ease of understanding,Graphs 200A through 200D are simplified presentations. In practice,spectrograms in which the Y axis represents frequency and thebrightness/color of the graph at a given X-Y coordinate may representamplitude of that frequency at that time.

Graph 200A represents an original master audio file stored on a centralserver. Segments 206, 208A, 210, 212A, and 214A represent identifiedfragmented segments in the audio file. In some embodiments, for example,these fragmented segments may be identified by spectrogram analysis andlabeled with a metadata tag. In other embodiments, an artist may havemanually fragmented the audio file into segments when the originalmaster audio file was created. Segments 206, 208A, 210, 212A, and 214Aare illustrated with black dots on each end of each line to signify thebeginning and end of the segment. To ease in understanding, segments206, 208A, 210, 212A, and 214A are all shown as straight lines. This issolely to simplify the presentation, and is not intended to limit theembodiments of this disclosure in any way. As is shown in FIGS. 2Bthrough 2D, a time segment may also be presented as a non-straight line,which is also for the purposes of presentation.

Graph 200B represents the audio data of an edited audio file uploaded byan artist. Segment 208B represents the artist's altered version ofsegment 208A. The curved nature of segment 208B may be, for example,because the artist felt an edit to segment 208A was necessary, butdesired to keep beginning of segment 210 unedited. Thus, the artist mayhave altered segment 208A, but caused the resulting edited segment torejoin with segment 210.

Segment 212B represents the artist's edit to segment 212A. As can beseen in FIG. 2B, edited segment 212B is slightly shorter in time thanoriginal segment 212A. Segment 216 is an added segment that was not inthe original master audio file, as can be seen by FIG. 2A. In addition,in order to accommodate new segment 216, it appears that the artistshifted segment 214B to a later point in the audio file, potentiallyextending the length of the audio file.

In some embodiments, the edits displayed by graph 200B may be acceptedinto a master audio file when the edits are uploaded. This is becausethere may be no edit conflicts (for example, if this is the first edituploaded by an artist).

However, graph 200C of FIG. 2C represents a subsequent edit to a secondcopy of the original audio file (e.g., a second edit to the datarepresented by graph 200A). As is illustrated, the only alteration madein this edited audio file is represented by segment 212C. Segment 212Crepresents an edited version of segment 212A. In some embodiments, thisedited segment may be uploaded by a second artist. In other embodiments,however, this edited segment may be uploaded by the same artist thatuploaded the data represented by graph 200B.

Upon being uploaded, graph 200C may trigger an outdated edit conflict.This is because the alterations to segment 212C rely upon segments 212Aand 214A, outdated segments; segment 212C begins where segment 212Aended and where segment 214A began. However, the current master file ofthe audio file includes segment 212B, which shifted the end of thesegment to earlier in the audio file. The current master file alsoincludes segment 214A, which shifted segment 214A to later in the audiofile. In the case that the uploading of segment 212C results in an editconflict, an artist working on the project (e.g., the artist whouploaded graph 200C) may be notified and provide a resolution. In otherembodiments, the system may utilize a machine-learning system to createa solution based upon learned preferences of the artists working on theproject and their end users.

Graph 200D of FIG. 2D represents a resolution to the edit conflictsresulting from the edits illustrated by 2B and 2C. As shown, graph 200Dmaintained edited segment 208B in the master audio file. This may bebecause, for example, an artist listened to both segments 208A and 208Band preferred segment 208B. This may also be because the systemrecognized that Segment 208A was not altered in the edits represented bygraph 200C (for example, because the artist did not attach an edit flagto segment 208A, and the system did not identify it as edited, orbecause the artist was notified of the edit conflict, listened to bothsegment 208A and 208B, and preferred 208B.

Segment 212D, however, represents a merger of segments 212B and 212C.Segment 212D may be created, for example, after a notified artistlistened to segments 212B, 216, and 214A and to segments 212C and 214A.The notified artist may have preferred the first section of segment212C, but also desired to keep segment 216. Thus, the artist may havecreated segment 212D to merge segment 212C into the edits that createdsegment 216 and shifted segment 214B.

In some descriptions of some embodiments of the present disclosure,users, such as artists, are notified in the event of an edit conflict.In some embodiments, those notified users may provide a resolution tothe conflict, such as selecting between two edited segments, or mergingtwo edited segments into a third edited segment. However, in someembodiments a machine-learning system, such as a neural-networkclassifier, can be utilized to resolve edit conflicts.

FIG. 3 illustrates an example method 300 in which a machine-learningsystem may be utilized to resolve edit conflicts during the developmentof an audio file. The machine-learning system may be, for example,located on a central server that maintains a current master audio file,or may be located on a second computer connected to the central server.

Method 300 begins with block 302 in which an edit conflict isidentified. This identification could be performed in any way consistentwith the embodiments of this disclosure, such as those described inmethod 100. Once an edit conflict is identified, the machine-learningsystem identifies users whose audio preferences are relevant toresolving the conflict. The types of relevant users may differ based onthe embodiment and use case. For example, in some embodiments a relevantuser may be an lead artist, such as a musician whose name is publiclyattached to a song in development. In other embodiments, the relevantuser may be a lead sound designer that is the head of anaudio-development project. In other embodiments, the relevant users maybe the end users of the audio file, such as the general public who willlisten to a song in development.

Once relevant users are identified, the preferences of the users areanalyzed in block 306 to identify patterns that may be relevant toresolving the edit conflict identified in block 302. If, for example therelevant user is a musician, the system may analyze songs by thatmusician to identify patterns in the musician's music. If, on the otherhand, the relevant user is a lead sound designer, the system may analyzepast resolutions that that sound designer (or other sound designers)have made in response to edit conflicts. The system may attempt toidentify patterns in those past resolutions that could be applied to thecurrent identified edit conflict. If, on the other hand, the relevantusers are the general public, the system may identify popular relevantsongs (e.g., popular songs in the same genre as the song in development)and analyze those songs for patterns that could be applied to theidentified edit conflict.

Finally, once the relevant user preferences are analyzed, the systemedits the master sound file in block 308 according to those preferencesin a way that resolves the edit conflict. In some embodiments, this mayentail selecting a segment between two conflicting segments that is morein line with the relevant user(s) preferences. In some embodiments, thismay also include adding new segments help implement artist-suppliededits into a master audio file. In some embodiments, this may includealtering a conflicting segment to align it more closely with thepreferences of the relevant user(s).

FIG. 4 depicts the representative major components of an exampleComputer System 401 that may be used in accordance with embodiments ofthe present disclosure. The particular components depicted are presentedfor the purpose of example only and are not necessarily the only suchvariations. The Computer System 401 may include a Processor 410, Memory420, an Input/Output Interface (also referred to herein as I/O or I/OInterface) 430, and a Main Bus 440. The Main Bus 440 may providecommunication pathways for the other components of the Computer System401. In some embodiments, the Main Bus 440 may connect to othercomponents such as a specialized digital signal processor (notdepicted).

The Processor 410 of the Computer System 401 may include one or moreCPUs 412. The Processor 410 may additionally include one or more memorybuffers or caches (not depicted) that provide temporary storage ofinstructions and data for the CPU 412. The CPU 412 may performinstructions on input provided from the caches or from the Memory 420and output the result to caches or the Memory 420. The CPU 412 mayinclude one or more circuits configured to perform one or methodsconsistent with embodiments of the present disclosure. In someembodiments, the Computer System 401 may contain multiple Processors 410typical of a relatively large system. In other embodiments, however, theComputer System 401 may be a single processor with a singular CPU 412.

The Memory 420 of the Computer System 401 may include a MemoryController 422 and one or more memory modules for temporarily orpermanently storing data (not depicted). In some embodiments, the Memory420 may include a random-access semiconductor memory, storage device, orstorage medium (either volatile or non-volatile) for storing data andprograms. The Memory Controller 422 may communicate with the Processor410, facilitating storage and retrieval of information in the memorymodules. The Memory Controller 422 may communicate with the I/OInterface 430, facilitating storage and retrieval of input or output inthe memory modules. In some embodiments, the memory modules may be dualin-line memory modules.

The I/O Interface 430 may include an I/O Bus 450, a Terminal Interface452, a Storage Interface 454, an I/O Device Interface 456, and a NetworkInterface 458. The I/O Interface 430 may connect the Main Bus 440 to theI/O Bus 450. The I/O Interface 430 may direct instructions and data fromthe Processor 410 and Memory 420 to the various interfaces of the I/OBus 450. The I/O Interface 430 may also direct instructions and datafrom the various interfaces of the I/O Bus 450 to the Processor 410 andMemory 420. The various interfaces may include the Terminal Interface452, the Storage Interface 454, the I/O Device Interface 456, and theNetwork Interface 458. In some embodiments, the various interfaces mayinclude a subset of the aforementioned interfaces (e.g., an embeddedcomputer system in an industrial application may not include theTerminal Interface 452 and the Storage Interface 454).

Logic modules throughout the Computer System 401—including but notlimited to the Memory 420, the Processor 410, and the I/O Interface430—may communicate failures and changes to one or more components to ahypervisor or operating system (not depicted). The hypervisor or theoperating system may allocate the various resources available in theComputer System 401 and track the location of data in Memory 420 and ofprocesses assigned to various CPUs 412. In embodiments that combine orrearrange elements, aspects of the logic modules' capabilities may becombined or redistributed. These variations would be apparent to oneskilled in the art.

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a computer, or other programmable data processing apparatusto produce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks. These computerreadable program instructions may also be stored in a computer readablestorage medium that can direct a computer, a programmable dataprocessing apparatus, and/or other devices to function in a particularmanner, such that the computer readable storage medium havinginstructions stored therein comprises an article of manufactureincluding instructions which implement aspects of the function/actspecified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be accomplished as one step, executed concurrently,substantially concurrently, in a partially or wholly temporallyoverlapping manner, or the blocks may sometimes be executed in thereverse order, depending upon the functionality involved. It will alsobe noted that each block of the block diagrams and/or flowchartillustration, and combinations of blocks in the block diagrams and/orflowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts orcarry out combinations of special purpose hardware and computerinstructions.

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

What is claimed is:
 1. A method comprising: storing a first version ofan audio file; fragmenting the audio file into at least a first timesegment; receiving a first edit to the audio file; identifying a firstedited version of the first time segment in the first edit; updating thefirst version of the audio file with the first edit, resulting in asecond version of the audio file comprising the first edited version ofthe first time segment; receiving a second edit to the first version ofthe audio file; identifying a second edited version of the first timesegment in the second edit; determining, based on the identifying thesecond edited version, that the second edit alters an outdated versionof the first time segment, resulting in an edit conflict; identifying arelevant user for the audio file, wherein the relevant user is amusician; analyzing preferences of the identified relevant user, whereinthe analyzing comprises analyzing publicly available songs released bythe musician; and editing, based on the analyzing, the audio file toresolve the edit conflict.
 2. The method of claim 1, further comprising:receiving a third edit to the second version of the audio file; anddetermining that the third edit resolves the edit conflict; wherein theediting comprises updating the second version of the audio file with thethird edit, resulting in a third version of the audio file.
 3. Themethod of claim 1, wherein the fragmenting comprises labeling each timesegment with a unique meta-data tag.
 4. The method of claim 1, furthercomprising: labeling, at the time of the fragmenting, the first timesegment with a first edit timestamp; labeling, at the time of theupdating, the first edited version of the first time segment with asecond edit timestamp; wherein the determining that the second editalters an outdated version of the first time segment comprises:determining that the first edited version of the first time segment inthe second version of the audio file comprises the second edittimestamp; determining that the second edited version of the first timesegment comprises the first edit timestamp; and determining that thefirst edit timestamp is older than the second edit timestamp.
 5. Themethod of claim 1, wherein the identifying the first edited version ofthe first time segment comprises detecting that the first edited versionof the first time segment is labeled with an edit meta-data tag.
 6. Themethod of claim 1, further comprising: identifying a first editedversion of a second time segment in the second edit; determining, basedon the identifying the first edited version of the second time segment,that the second edit alters a current version of the second timesegment; and updating the second version of the audio file, resulting ina third version of the audio file comprising the first edited version ofthe second time segment.
 7. The method of claim 1, wherein theidentifying a first edited version of the first time segment comprises:identifying a first set of segments in the stored audio file;determining that the first edited version of the first time segmentcorresponds to an original version of the first time segment in thefirst version of the audio file; and detecting that the first editedversion of the first time segment is not identical to the originalversion of the first timestamp.
 8. A system comprising: a processor; anda memory in communication with the processor, the memory containingprogram instructions that, when executed by the processor, areconfigured to cause the processor to perform a method, the methodcomprising: receiving a first edit to an audio file; receiving a secondedit to the audio file; detecting an edit conflict between the firstedit and the second edit; identifying a relevant user for the audiofile, wherein the relevant user is the general public; analyzepreferences of the identified relevant user, wherein the analyzingcomprises: identifying a set of songs that are popular with the generalpublic; and analyzing the songs in the set of songs; and edit, based onthe analyzing, the audio file to resolve the edit conflict.
 9. Thesystem of claim 8, further comprising identifying a genre of the audiofile, wherein each song in the set of songs comprises the genre.
 10. Acomputer program product, the computer program product comprising acomputer readable storage medium having program instructions embodiedtherewith, the program instructions executable by a computer to causethe computer to: store a first version of an audio file; fragment theaudio file into at least a first time segment; receive a first edit tothe audio file; identify a first edited version of the first timesegment in the first edit; update the first version of the audio filewith the first edit, resulting in a second version of the audio filecomprising the first edited version of the first time segment; receive asecond edit to the first version of the audio file; identify a secondedited version of the first time segment in the second edit; determine,based on the identifying the second edited version, that the second editalters an outdated version of the first time segment, resulting in anedit conflict; identify a relevant user for the audio file wherein therelevant user is a musician; analyze preferences of the identifiedrelevant user, wherein the analyzing comprises analyzing publiclyavailable songs released by the musician; and edit, based on theanalyzing, the audio file to resolve the edit conflict.
 11. The computerprogram product of claim 10, wherein the program instructions furthercause the computer to: receive a third edit to the second version of theaudio file; determine that the third edit resolves the edit conflict;and wherein the editing comprises updating the second version of theaudio file with the third edit, resulting in a third version of theaudio file.
 12. The computer program product of claim 10, wherein thefragmenting comprises labeling each time segment with a unique meta-datatag.
 13. The computer program product of claim 10, wherein the programinstructions further cause the computer to: label, at the time of thefragmenting, the first time segment with a first edit timestamp; label,at the time of the updating, the first edited version of the first timesegment with a second edit timestamp; wherein the determining that thesecond edit alters an outdated version of the first time segmentcomprises: determine that the first edited version of the first timesegment in the second version of the audio file comprises the secondedit timestamp; determine that the second edited version of the firsttime segment comprises the first edit timestamp; and determine that thefirst edit timestamp is older than the second edit timestamp.
 14. Thecomputer program product of claim 10, wherein the identifying the firstedited version of the first time segment comprises detecting that thefirst edited version of the first time segment is labeled with an editmeta-data tag.
 15. The computer program product of claim 10, wherein theprogram instructions further cause the computer to: identify a firstedited version of a second time segment in the second edit; determine,based on the identifying the first edited version of the second timesegment, that the second edit alters a current version of the secondtime segment; and update the second version of the audio file, resultingin a third version of the audio file comprising the first edited versionof the second time segment.
 16. The computer program product of claim10, wherein the identifying a first edited version of the first timesegment comprises: identifying a first set of segments in the storedaudio file; determining that the first edited version of the first timesegment corresponds to an original version of the first time segment inthe first version of the audio file; and detecting that the first editedversion of the first time segment is not identical to the originalversion of the first timestamp.